Shows how the Kinematic Layer of the KMotion Libraries can be used to handle non-linear Kinematics.  Once that is developed the GCode can simply operate in normal xyz Cartesian coordinates. Feed rate and Jogging in simple Cartesian coordinates as well.

You must code in C++ the equations to transform CAD space to actuator space for your system.  See the CKinematics3Rod.cpp example.  For the 3 linear actuators in the video the equations are fairly simple.  Given the xyz CAD position the actuator lengths are simply the distances from the CAD position to each of the actuator positions.  Here is the code used:

    // find lengths of each actuator

    GeoCorrect(x,y,z,&x,&y,&z);

    double r0 = sqrt(sqr(x-Act0Center.x) + sqr(y-Act0Center.y) + sqr(z-Act0Center.z)) - Act0Off;
    double r1 = sqrt(sqr(x-Act1Center.x) + sqr(y-Act1Center.y) + sqr(z-Act1Center.z)) - Act1Off;
    double r2 = sqrt(sqr(x-Act2Center.x) + sqr(y-Act2Center.y) + sqr(z-Act2Center.z)) - Act2Off;

Because in our mechanical arrangement this model is not exactly correct (the motors/end effector pivot slightly) this results in a close approximation, but not a perfect solution, so we also apply a Geometric Correction Table to correct for minor residual errors.  Even if the model was perfect it would be difficult to know all the parameters accurately enough to get a perfect result.  So the Geometric Correction capability comes in handy.   The Geometric Correction Table is determined empirically by moving the system to known points on a grid and recording the actuator positions.  See:

Only the Inverse Kinematics equations are required which are relatively simple in this case.  The Forward Kinematics (going from actuator lengths to CAD Position would be more difficult and require solving the intersection of 3 spheres) is not required.  Any GeoCorrection complicates things further.  But KMotion will numerically find that for you given only the Inverse Kinematics so you needn't be concerned with it.

HTH

Regards

TK